Not much has changed since my previous post, Subversion and Git are still growing.

Zack has a similar graph with a logarithmic y-axis which shows that arch is losing users. Who would have thought? :)

Totally awesome: Moodstream. Yet another evil Flash-only site, but this one is worth it.

Pretty cool: code_swarm, an experiment in organic software visualization . Check out the Python video.

Sucks big time: having to wait until February 2009 for the end of BSG season four. Not sure I'll have the strength.

The favorites mosaic shown in my previous post was a good excuse for me to try out Flickr's API, and it turned out to be a lot easier than I thought. So if, like me, you feel like playing with 2.5 billion photos (and 5,000 new uploads every minute), here's a quick guide.

All you need is an API key (get one here) and a set of bindings for your favorite language. I'm a Python person so I had two choices: Beej's Flickr API and flickr.py; the latter seemed to have everything I needed in a single file, so I went with it. It provides classes directly mapped to most of Flickr's concepts: photos, tags, sets, groups, users, etc.

To get started, let's see what Flickr knows about me (if you don't know your Flickr user id, get it from the RSS link in your photo page):

>>> me = flickr.User('99746300@N00')
>>> me.username, me.ispro,  me.location, me.photos_count
(u'orebokech', u'1', u'Lyon, France', u'254')
>>>

Sounds right. Now, to create my favorites mosaic I need to get the list of my favorites, actually I only need 36 of them. Easy:

>>> faves = me.getPublicFavorites(per_page=36)
>>> len(faves)
36
>>>

You can iterate over the list and get flickr.Photo objects which have all the information you need, like the available sizes of the image:

>>> photo = faves[0] # let's just get one for this example
>>> for size in photo.getSizes():
...     print "%s: %dx%d" % (size['label'], size['width'], size['height'])
Square: 75x75
Thumbnail: 100x67
Small: 240x160
Medium: 500x333
Original: 1024x683
>>>

And for each available size you can get the corresponding photo page, or the URL to the image itself:

>>> photo.getURL() # photo page, default Medium
u'http://www.flickr.com/photos/o0off/2363681897/sizes/m/'
>>> photo.getURL(size='Square', urlType='source') # img
u'http://farm3.static.flickr.com/2107/2363681897_f6528a14a4_s.jpg'
>>>

Add a little bit of HTML formatting around this, and you get a neat mosaic. The concept can trivially be extended to sets, tag searches, etc. It's all very straightforward.

Phew, this post is getting pretty long, so I think I'll leave you to explore the rest for yourself. Have fun!

The folks at the Caja project have compiled a great list of known attack vectors against Javascript engines and browsers, complete with detailed descriptions and examples.

If you're interested in web security, this paper on Caja is a great read (and the project is worth keeping an eye on).

CVE-2007-5962, made public yesterday:

Memory leak in a certain Red Hat patch, applied to vsftpd 2.0.5 on Red Hat Enterprise Linux (RHEL) 5 and Fedora 6 through 8, and on Foresight Linux and rPath appliances, allows remote attackers to cause a denial of service (memory consumption) via a large number of CWD commands, as demonstrated by an attack on a daemon with the deny_file configuration option.

Rather embarrassing given vsftpd's focus on security... Of course this is nowhere near the scale of last week's OpenSSL bug, but it seems to indicate that Debian is not the only distro with insufficient review processes. (The patch was added in 2006 to fix this bug.)

The OpenSSL fiasco has started a fresh discussion on Debian source packages and the way we handle changes to upstream software. One of the issues under discussion is that some Debian packages don't use a patch system and ship all their modifications unseparated in the Debian .diff.gz, which makes it harder or impossible to extract patches later on and to understand why some changes were made. The commonly recommended way of doing things is instead to keep the upstream source pristine, storing modifications cleanly separated and documented under debian/patches; several tools such as quilt or dpatch can make this process easy.

Out of curiosity, I did a quick scan of my local mirror to see how many packages ship changes outside debian/ in their .diff.gz, and I was surprised to see that 4803 source packages out of 11853 (40%) do so! This is much more than I expected. Some packages even use a patch system but still have changes in .diff.gz, as shown by this lintian check.

The most commonly patched files in affected packages are:

   1006 config.sub
   1002 config.guess
    823 Makefile
    754 configure
    715 Makefile.in
    484 aclocal.m4

Most of these are caused by autotools updates which are necessary if upstream ships old versions of these files. In many cases there are clean ways to deal with this, for example to always have up-to-date versions of config. guess,sub you can simply make them re-exec their authoritative versions (as shown by this patch) and build-depend on autotools-dev.

If you don't use a patch system, now is a good time to start. The New Maintainers' guide has more information on the topic.

For a split second, in the opening shot of The Peanut Reaction , I had the impression that Rajesh's laptop was running some sort of GNOME desktop, but it soon becomes apparent that it's actually running Mac OS X. Sheesh. When is Linux going to become mainstream?

Gabl (the incredible indie no-longer-one-man band/art collective from back home) have released their new video: Drunk Fox in London . As you might have guessed it features an intoxicated fox, which I like to think has a passing resemblance to Firefox's mascot. Check it out!

Nice long rant from Stevey on why XEmacs needs to be put out of its misery: XEmacs is Dead. Long Live XEmacs! .

• The smallwig theory of optimization
  +1
• Facebook knows who you are, and that's worth more than you think
  Still, I think Facebook is grossly overvalued.
• Good Times
  Indeed.
• It is the future now
  ... in California.
• Natural History
  More from Andrew Bird and his next album.

Come on, Microsoft. Seriously. WTF?

• Words Will Tell
  Andrew Bird on songmaking.
• Says it all really ....
  (applies to all online collaboration tools)
• Talk on disk as the new RAM
• Wii hacking and the Freeloader
  "Since such an important component failed open, it s clear higher assurance development techniques are needed for software protection and crypto."

In case anyone out there is using my dcmd script, I'll note that it's now included in devscripts (starting with version 2.10.20). The devscripts version doesn't behave differently when called as dscp or drsync, I have the following aliases to get the old behavior:

alias dscp='dcmd scp'
alias drsync='dcmd rsync -av'

As always, feedback welcome.

• Translation From MS-Speak to English of Selected Portions of Joel Spolsky s Martian Headsets
  Haha.
• Robots are getting better...the Big Dog robot can recover itself...
  Watch the video!
• Apple iPhone bootloader attack
• APIs: "Easy to Use" vs "Hard to Misuse"

The status page speaks for itself: most of GNOME 2.22 is now available in sid. A few packages are being staged in experimental to avoid breaking too much stuff, and a few of the remaining missing pieces are waiting in NEW. Special thanks to Sebastian Dr ge who's done an incredible work with more than 90 uploads over the past week!

• Security futurists shun perimeter, anti-virus systems
• Battlestar Galactica Last Supper
  (warning, image contains spoilers)
• An hour and a half with Barack Obama
  He'd get my vote.

Today I discovered that I have a nightly cron job on one of my machines to generate the Vcs statistics I mentioned previously; somehow I had forgotten. So here's an updated graph:

Subversion and Git are still growing fast, the others aren't very successful. 18.8% of all source packages in main are maintained in Subversion, and Git is up to 4.3%.

It's also interesting to note that 91% of the packages maintained in Subversion are hosted on Alioth (svn.debian.org) whereas 77% of the packages maintained in Git are on git.debian.org.

After using Firefox 3 Beta 4 (built from source) for a few hours, I'm pretty impressed:

• Google Reader is much, much faster. Since I spend a fair amount of time in it every day, it's a welcome improvement. Overall, the browser feels faster.
• Widgets now have a native GTK+ look'n'feel, and the user interface is more polished. Nice.
• The address bar has a new completion strategy which is... weird. It now shows the title of the history item as well as the address itself, resulting in an unnecessarily large box. I'll have to get used to it.
• Search Keys says that it doesn't support Beta 4, but it does. Just edit the xpi and change the version range in the rdf file. Can't live without it!
• Memory-wise, it seems better than Firefox 2, but not strikingly so.

Now I just have to wait for Iceweasel 3.0, and in the meantime I won't be going back to version 2.0!

So, since Emacs is apparently switching to bzr, I thought I'd try it out. The first thing I noticed is that cloning the repository is very slow. So slow that I killed it, thinking that it was stuck, but it wasn't. It turns out that the official page recommends downloading a tarball instead, so I did that.

Once I had my local Emacs branch, I tried a simple bzr log to see how recent the repository was. It sat there for a whole minute before even starting to show something. Apparently, all the history commands are slow... This is with a hot cache:

$ time bzr log >/dev/null
bzr log > /dev/null  44.89s user 0.58s system 99% cpu 45.563 total
$ time bzr version-info
revision-id: cvs-1:monnier-20080313012033-9ewl8gg4q3bw01z3
date: 2008-03-13 01:20:33 +0000
build-date: 2008-03-13 20:14:17 +0100
revno: 87445
branch-nick: sandbox
bzr version-info  6.41s user 0.14s system 99% cpu 6.549 total
$

Six seconds just to show me the current revision?!

Compare with my favorite scm, in a repository that contains the same history, also converted with cvsps:

$ time git log >/dev/null
git log > /dev/null  1.81s user 0.05s system 99% cpu 1.862 total
$ time git show >/dev/null
git show > /dev/null  0.02s user 0.00s system 85% cpu 0.023 total
$

Fortunately, other bzr commands such as status, diff, commit are pretty fast so this might be a problem with the conversion process, or something. At least I hope so, because as is it's completely unusable!

• Comic for 02 Mar 2008
  I KNEW it!
• Coming Soon from VW: A 69.9 MPG Diesel Hybrid
• Real-world Performance Tuning with Callgrind
  Neat, but good old gprof would have caught that kind of thing too.
• Optical Illusion
  It works.